Spotlight Unraveling the Web Services Web

Description WSDL defines a service’s abstract description in terms of messages exchanged in a service interaction. There are three main components of this abstract interface: the vocabulary, the message, and the interaction. Agreement on a vocabulary is the foundation of any type of communication. WSDL uses external type systems to provide datatype definitions for the information exchange. Although WSDL can support any type system, most services use XSD. Figure 5 shows two data types defined in XSD (string and int), and two data types defined in external schema (Flight 88 MARCH • APRIL 2002 http://computer.org/internet/ IEEE INTERNET COMPUTING Spotlight POST /travelservice SOAPAction: “http://www.acme-travel.com/flightinfo” Content-Type: text/xml; charset=“utf-8” Content-Length: nnnn UL 506 Figure 3. SOAP RPC call.To find out if his flight is on time, Joe sends a string containing the airline’s name and an integer with the flight number. InfoType and Ticket). WSDL can import such external XSD definitions using an “import” element specifying their location. WSDL defines message elements as aggregations of parts, each of which is described by XSD types or elements from a predefined vocabulary. Messages provide an abstract, typed data definition sent to and from the services. The example in Figure 5 shows the three messages that might appear during a Web services interaction. The message, GetFlightInfoInput, has two parts: airlineName, which is an XSD string, and flightNumber, which is an XSD integer. The other two messages, GetFlightInfoOutput and CheckInInput have only one part each. The operation and portType elements combine messages to define interactions. Each operation represents a message exchange pattern that the Web service supports, giving users access to a certain basic piece of service functionality. An operation is simply a combination of messages labeled as input, output, or fault to indicate what part a particular message plays in the interaction. A portType is a collection of operations that are collectively supported by an end point. In our example, AirportServicePortType describes two operations: a single request-response operation, GetFlightInfo, which expects the GetFlight InfoInput message as input and returns a GetFlightInfoOutput message as the response; and a one-way operation, CheckIn, which just takes the CheckInInput message as input. Concrete Binding Information So far, all of the elements that we have discussed describe the service’s application-level functionality. To complete the description of client–service interaction, we need three more pieces of information: what communication protocol to use (such as SOAP over HTTP), how to accomplish individual service interactions over this protocol, and where to terminate communication (the network address). WSDL’s binding element provides the “what” and “how” parts of this information, including the communication protocol and data format specification for a complete portType. In short, the binding element tells how a given interaction occurs over the specified protocol. Figure 6 (next page) shows a fragment from our example. The binding describes how to use SOAP to access the travelservice serIEEE INTERNET COMPUTING http://computer.org/internet/ MARCH • APRIL 2002 89 Web Services HTTP/1.1 200 OK Content-Type: text/xml; charset=“utf-8” Content-Length: nnnn 10 ON TIME Figure 4. SOAP RPC response.The travel service responds to Joe’s request with a structured value containing subvalues for gate number and flight status. Figure 5.WSDL abstract description.This fragment shows the string and int data types,which are defined in XSD,and two other data types defined in external schema:FlightInfoType and Ticket,which we assume were imported earlier in the WSDL file. vice. In particular, the WSDL document shows that GetFlightInfo will be a SOAP-RPC-style interaction, in which all message exchanges use standard SOAP encoding, and CheckIn is a pure messaging interaction (“document-oriented,” in WSDL terms) in which the SOAP message’s body contains the encoded message with no additional type encoding; that is, it uses XSD to literally describe the transmitted XML. All that remains now is to define “where” to access this combination of abstract interface and protocol and data marshalling details (the binding). A port element describes a single end point as a combination of a binding and a network address. Consequently, a service element groups a set of related ports. In our travel service example, a single port describes an end point that processes SOAP requests for the travelservice service. Using WSDL For users and developers, WSDL provides a formalized description of client–service interaction. During development, developers use WSDL as the input to a proxy generator that produces client code according to the service requirements. WSDL can also be used as input to a dynamic invocation proxy, which can then generate the correct service requests at runtime. The result in both cases is to relieve the user and developer of the need to remember or understand all the details of service access. For example, travel service users need only obtain the WSDL description and use it as input to the tooling and runtime infrastructure to exchange the correct SOAP message types with the service. Discovery: UDDI The Universal Description, Discovery, and Integration specifications offer users a unified and systematic way to find service providers through a centralized registry of services that is roughly equivalent to an automated online “phone directory” of Web services. The browser-accessible UDDI Business Registry (UBR) became available shortly after the specification went public. Several individual companies and industry groups are also starting to use “private” UDDI directories to integrate and streamline access to their internal services. UDDI provides two basic specifications that define a service registry’s structure and operation: a definition of the information to provide about each service, and how to encode it; and a query and update API for the registry that describes how this information can be accessed and updated. Registry access is accomplished using a standard SOAP API for both querying and updating. Here we focus on the first aspect, which provides a good idea of how the registry operates. Organizing Structure UDDI encodes three types of information about Web services: 90 MARCH • APRIL 2002 http://computer.org/internet/ IEEE INTERNET COMPUTING Spotlight Figure 6.WSDL’s concrete binding information. As this fragment shows,GetFlightInfo is a SOAP RPC interaction and CheckIn is a pure messaging interaction that uses XSD to describe the transmitted XML. “white pages” information includes name and contact details; “yellow pages” information provides a categorization based on business and service types; and “green pages” information includes technical data about the services. The UDDI registry is organized around two fundamental entities that describe businesses and the services they provide. The businessEntity element illustrated in Figure 7 provides standard white-pages information, including identifiers (tax IDs, social security numbers, and so on), contact information, and a simple description. Each business entity might include one or more businessService elements, shown in Figure 8 (next page), that represent the services it provides. Both business and service entities can specify a categoryBag to categorize the business or service (we discuss later how to encode this information). Figures 7 and 8 (next page) show an important aspect of UDDI’s design: Unique keys identify each data entity — businesses, services, and so on — that might be cross-referenced. These assigned keys are long hexadecimal strings generated when the entity (in this case, a business) is registered. The keys are guaranteed to be universally unique identifiers (UUIDs). For example, the businessKey attribute uniquely identifies a business entity and the serviceKey attribute identifies a service. A service also references its host by its business key. In addition to a human-readable description, name, and categorization, the service entity contains a list of bindingTemplates that encode the technical service-access information. Each binding template represents an access point to the service. The assumption is that the same service can be provided at different endpoints, each of which might have different technical characteristics. Technical Descriptions and tModels A closer look at the binding template shows a great deal about how UDDI enables business and service descriptions using arbitrary external information (that is, information that is not defined by UDDI itself). Most of the information in a binding template is what we would naturally expect for an endpoint. Foremost is the end point address where the service can be accessed. This address might be a URL, e-mail address, or even a phone number. We also find the expected unique key (binding Key) and a cross-reference to the service key. The most interesting field, however, is tModelInstanceDetails, which provides the service’s technical description (the green-pages information). The field contains a list of references to the technical specifications with which the service complies. The service provider first registers the required technical specifications in the directory, which assigns a corresponding unique identifier key. UDDI represents each registered technical specification using a new information entity, the tModel. Service endpoints that support the specification can then simply add the corresponding reference to their tModelInstanceDetails list. As an example, let’s say we want to register a WSDL document as a tModel. Assuming that the travel industry has defined the standard WSDL interfaces and bindings for electronic check-in and retrieval of flight information, we first create a tModel like the one in Figure 9 (page 93) to represent these WSDL definitions. Service end points that implement those interfaces can then include IEEE INTERNET COMPUTING http://computer.org/internet/ MARCH • APRIL 2002 91 Web Services Acme Travel Incorporated Acme is a world leader in online travel services Acme Inc. 1 800 CALL ACME [email protected] Acme 12 Maple Avenue Springfield, CT 06785 ... ... ... Figure 7. Simplified businessEntity structure.This element offers standard white-pages information, including contact information and basic service descriptions.